為什麼我們會選擇在我們的專案中使用 Kotlin？開發者經常被 Kotlin 的簡潔性或獨特的功能所吸引。而對於商業應用來說，真正令人信服的是 Kotlin 的安全性 - 其設計如何消除潛在的應用錯誤。當一個應用崩潰或者一個網站出現錯誤，導致花了一個小時將產品加入購物車後無法結賬時，你不需要有任何開發經驗也會感到不悅。更少的崩潰不僅改善了用戶的生活，也為開發者帶來了巨大的商業價值。

以上是可以用來說服老闆嘗試 Kotlin 的說帖

所以對開發者來說安全性是非常重要的，而 Kotlin 是一個非常安全的語言，但仍然需要開發者的支持才能真正安全。之後幾天我們將討論 Kotlin 中最重要的安全性最佳實踐。我們將了解 Kotlin 的功能如何促進安全性，以及我們如何正確地使用它們。

變數的危險性

承上，所以 Effective Kotlin 書中第一條就是安全性，而第一個要點就是利用限制可變性 (Limit mutability) 來大量減少出錯的風險和維護的困難度

舉個例子，如果設計一個銀行帳戶的類別，資金餘額就是一個狀態。這個狀態會因為存提款等操作而變化，讓程式碼變得更複雜。解決的方式就是要麼限制這個狀態的變動，要麼紀錄所有變動以方便追蹤 (Event Sourcing)。

class BankAccount {
  var balance = 0.0
  private set

  fun deposit(depositAmount: Double) {
    balance += depositAmount
  }

  @Throws(InsufficientFunds::class)
  fun withdraw(withdrawAmount: Double) {
    if (balance < withdrawAmount) {
      throw InsufficientFunds()
    }
  balance -= withdrawAmount
  }
}


 class InsufficientFunds : Exception()

 val account = BankAccount()
 println(account.balance) // 0.0
 account.deposit(100.0)
 println(account.balance) // 100.0
 account.withdraw(50.0)
 println(account.balance) // 50.0

在這裡，BankAccount 類別有一個狀態，代表帳戶中有多少錢。持有狀態是一把雙面刃。一方面，它很有用，因為它可以表示隨時間變化的元素。另一方面，狀態管理很困難，原因有三：

1. 程式中有很多可變點時，要理解和調試這個程式就更困難了。這些變化點之間的關係需要被理解，並且當更多的變化發生時，追蹤它們是如何改變的就更加困難。一個有很多相互依賴的可變點的類別通常很難理解和修改，特別是在出現意外情況或錯誤的時候。
2. 可變性使得推理代碼變得更困難。一個不可變元素的狀態是明確的，但一個可變的狀態則更難以理解。由於其值可能在任何時候改變，因此即使我們可能剛剛檢查過，它也可能已經變了。
3. 在多線程程式中，可變狀態需要適當的同步。每一次變化都是一個潛在的衝突。

可變的變數讓我們不只依賴狀態，還依賴他的歷史

好工具要好習慣

Kotlin 的設計理念和靈活的語法讓我們能夠寫出更安全、更高效的代碼，但前提是開發者需要遵循一些最佳實踐，以確保這些優點能夠完全發揮。從這個角度看，安全性不僅是語言本身的特性，也是開發過程中需要持續關注的議題。

Kotlin提供了許多工具來限制可變性，並幫助不可變性。我們應該使用它們來限制變更點。以下是一些簡單的規則：
• 優先選擇 val 而不是 var
• 優先選擇不可變的屬性而不是可變的屬性
• 優先選擇不可變的對象和類別，而不是可變的
• 如果您需要物件進行更改，考慮使用 data calss with val 並使用 copy
• 當您保有一個狀態時，優先選擇唯讀集合
• 不要暴露可變物件

我們將在接下來幾天討論這些規則，這是大多情況的建議選擇。更後面談到效能時，也有為了效能調核，增加可變點，這也是 Kotlin 帶給我們的彈性。

每日一推 (G)I-DLE

播放次數 1.2億的 화(火花)(HWAA)